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Computer program development by stepwise refinement has been 
advocated by many people. We take another look at stepwise refine- 
ment in light of recent developments in programming languages and 
programming methodology such as abstract data types, correctness 
proofs and formal specifications, parallel programs and multiversion 
programs. We offer suggestions for the refinement process and discuss 
program maintainability. 



I. INTRODUCTION 

The correct design of nontrivial programs and systems of programs 
is an intellectually challenging and difficult task. Often programs are 
designed with very little time spent on the design itself, the effort 
being concentrated on coding. This could be due to management's 
desire to see something working as soon as possible to be assured that 
work is progressing, or it could be due to the programmer's desire to 
"attack the problem right away." 

Not only is there no emphasis on design, the approach to it is also 
not systematic or disciplined. This results in programs that do not 
meet specifications in terms of correct output and performance require- 
ments. 

What we want is a programming methodology that puts some 
discipline and structure in the design process without stifling creativity. 
A programming methodology should: 

(i) Help us master the complexity of the problem being solved and 
give us some guidelines on how to formulate the problem solution. 

(ii) Provide us with a written record of the design process. The 
design can then be read by others, and the design decisions can be 
appreciated or constructively criticized. 

{Hi) Result in programs that are understandable. 
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(iv) Lead to programs whose correctness can be verified by proofs. 
Since proofs are difficult, the methodology should allow for a sys- 
tematic approach to program testing. 

(u) Be generally applicable and not restricted to a class of problems. 

(vi) Allow for the production of efficient programs. 

(vii) Allow for the production of programs that can be modified 
systematically. 

In this tutorial we discuss a programming methodology called step- 
wise refinement and informally show that it satisfies these criteria. 

II. STEPWISE REFINEMENT 

Stepwise refinement is a top-down design approach to program 
development (first advocated by Wirth 4 ). Wirth really gave a sys- 
tematic formulation and description of what many programmers were 
previously doing intuitively. According to Brooks, 2 stepwise refinement 
is the most important new programming formalization of the decade. 
Stepwise refinement is applicable not only to program design, but also 
to the design of complex systems. 

In a top-down approach, the problem to be solved is decomposed or 
refined into subproblems which are then solved. The decomposition or 
refinement should be such that: 3,4 

(i) The subproblems should be solvable. 

(ii) A subproblem should be solvable with as little impact on the 
other subproblems as possible. 

(Hi) The solution of each subproblem should involve less effort than 
the original problem. 

(iv) Once the subproblems are solved, the solution of the problem 
should not require much additional effort. 

This process is repeated on the subproblems; of course, if the solution 
of a problem is obvious or trivial, then this decomposition is not 
necessary. 

If Po is the initial problem formulation/solution, then the final 
problem formulation/solution P„ (an executable program) is arrived 
at after a series of gradual "refinement" steps, 

Po=*Pi=>P 2 => ••• =>Pn- 

The refinement P,+i of P, is produced by supplying more details for 
the problem formulation/solution Pi. The refinements Po, • • • , Pn 
represent different levels of abstraction. Po may be said to give the 
most abstract view of the problem solution P„, while P„ represents a 
detailed version of the solution for Po. 

As an example of abstraction levels, consider a program that auto- 
mates the record-keeping of an insurance company. At the highest 
level of abstraction, the program deals with the insurance company as 
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an entity. At succeeding lower levels of abstraction, the program deals 
with 

• different insurance categories (auto, home, life, etc.) 

• groups of policies in the above categories 

• individual policies in the above groups 

• details of individual policies 

Each refinement P, consists of a sequence of instructions and data 
descriptions Py, 

Pa 



In each refinement step, we provide more details on how each P, is to 
be implemented. The refinement process stops when we reach a stage 

(i) where all the instructions can be executed on a computer, or 

{ii) where instructions can be easily translated to computer execut- 
able instructions. 

Pictorially, the refinement process may be depicted as shown in 
Fig. 1. The final program is a collection of the nodes at the last 
refinement level P n ■ 

The design can be probed to any desired level of detail i (0 < i < n). 
Understanding the design process is aided by the fact that level i 
provides an overview of levels i + 1 through n. 

We illustrate the stepwise refinement process with annotated ex- 
amples. The notation we will use for conveying our ideas will be 
Pascal-like 5 and include guarded commands. 6 pl/i will be used to show 
the executable versions of some programs. 



I 1 — I 

1 i i 



Fig. 1 — The refinement process. 
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The guarded commands are 
(i) Selection 

if b, -> SL, 
[]b 2 -* SL 2 

[]b n -* SL n 
fi 

The Ws are called the guards (Boolean expressions) and the SLi are 
statement lists. For a successful execution of the selection statement, 
at least one of the guards must be true. If only one guard is true, then 
the corresponding statement list is executed. If more than one guard 
is true, then one of the corresponding statement lists is selected 
nondeterministically (i.e., the user cannot tell beforehand) and exe- 
cuted, e.g., 



if a > b 


-> 


max 


= a 


[]6>a 


— > 


max 


= b 


fi 









If a = b, then both the guards are true and either of the statements 
max := a or max := b may be executed. Either way, the answer is 
right. This symmetry is aesthetically pleasing when compared to 
conventional deterministic programming. 
(ii) Repetition 

do fa, -► SL, 
[]b 2 -> SL 2 

[]b n -> SL n 
od 

The loop is repeatedly executed as long as one of the guards is true. 
If one guard is true, then the corresponding statement list is executed. 
As in the selection statement, if more than one guard is true, then one 
of the corresponding lists is arbitrarily selected and executed. 

Implementation of these statements in C, Pascal, pl/i, etc., will be 
deterministic. For example, in pl/i: 

(i) Selection 

IFb, 

THEN DO; SL,; END; 

ELSE IF b 2 THEN DO; SL 2 ; END; 

ELSE IF b n THEN DO; SL n ; END; 
ELSE ERROR; 
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(ii) Repetition 

L:DO WHILE ('1' 8); 
IFb, 

THEN DO; SL,; END; 

ELSE IF b 2 THEN DO; SL 2 ; END; 

ELSE IF b n THEN DO; SL n ; END; 
ELSE GOTO LE; 
ENDL; 
LE:; 

Note: These statements could be more conveniently implemented 
using the new pl/i SELECT and LEAVE statements. 

III. EXAMPLES OF STEPWISE REFINEMENT 

The examples used to illustrate stepwise refinement are small out of 
necessity. The reader is encouraged to apply stepwise refinement to 
larger problems. 

Example 1 

Write a program to simulate a week in John's life. 
Initial refinement Pq\ 

Simulate a week in John's life 

If we were programming in a language that understood the above 
instruction, then we wouldn't have to refine it further. 

Refinement P\ : 

a. d := monday (next day to be simulated is d} 

b. repeat 

c. simulate day d in John's life 

d. d := next day 

e. until week over 

A refinement consists of programming language instructions mixed 
with English statements. 

Refinement P2 : 

Line c of Pi is refined as 

Sleep until alarm goes off 
Go through morning ritual 
Spend the day 
Go through evening ritual 
Prepare to sleep 

Line d is refined as 
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if d = Sunday — > d:=monday 
[]d y± Sunday -+ d := SUCC(d) 
fi 

where the Pascal function SUCC gives the next day in the range of 
values monday, tuesday, • • • , Sunday. Line e: "week over" is refined as 
"d = monday." 

Collecting these refinements of Pi's instructions, we get refinement 
P 2 . 

d := monday 
repeat 

Sleep until alarm goes off 

Go through morning ritual 

Spend the day 

Go through the evening ritual 

Prepare to sleep 

if d = Sunday -* d := monday 

[]d * Sunday -* d := SUCC(d) 

fi 

until d = monday. 

This collection can be done mechanically and we shall in general omit 
it. 

"Spend the day" may be refined as 

if weekday — » go to work 

work 

return home 
[]weekend — » read newspaper 

laze around 

read book 

watch TV 
fi 

Similarly, the other instructions of P2 may be refined and the 
refinement process continued to the desired level of detail. In the 
refinement we have tried to model processes of the problem domain. 7 

An initial decomposition might not be feasible or nice, in which case 
we back up and try another decomposition. We shall only present the 
final set of decompositions. 

Example 2 

Write a program that reads in a list of positive numbers ai, 02, 
• • • , a„ (n > 0) and prints the sums of all natural numbers up to each 
a,, i.e., the sums: 



"1 


"2 


a n 


2i 


li, • 


•■ li- 


1=0 


i-0 


1=0 
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Initial refinement Po: Print £?=o i, £?J i, • • •, £?=o i- 

Pt: 

read a 

do while there 

a 

exists data — » Compute sum = JJ /'. 

Print sum 
read a 
od 

Because we are aiming for an executable program in a sequential 
programming language, the refinement Pi reflects the decision to read 
in an input element, compute its sum, print the sum, and then read 
another input element. Alternately, had our target been a parallel 
computer we would have probably read in all the input elements, 
computed the sums in parallel, and then printed them out. Many 
implicit decisions underlie every refinement. 

P 2 : • while there exist data 
is refined to 
not EOF 
• Compute sum = £?-o i 
is refined to 
/:=0 

sum := {sum = + 1 +2+ •••+/} 

do / 9* a -» /':=/'+ 1 ; sum : = sum + / od 
Let us now examine the concept of a loop invariant. A loop invariant 
is an assertion about program variables; it statically captures the 
meaning of a loop thus helping us understand it. Loop invariants are 
true before and after the execution of a loop, and before and after each 
execution of the loop body. Dijkstra 6 suggests some ways of finding 
the loop invariant using the desired post- condition (state of variables 
after the loop terminates). The loop invariant can actually aid in 
determining the guards and the corresponding statement lists. 

Let J be the loop invariant sum = + 1 + 2 + • • • + i. I is true 
initially because i = and sum = 0. Evaluation of the guard i 5^ a does 
not affect I; the statement i := i + 1 destroys 7, resulting in sum = 
+ 1 + 2+ • • • + i — 1. But sum = sum + i restores the validity of 
invariant I. When the guard evaluates to false, i.e., i = a, the loop 
terminates. Now in addition to I being true we have i = a, implying 
the desired result sum = + 1 + 2+ ••• +a. 

How can we demonstrate loop termination? For this we must show 
the existence of a function, initially > 0, whose value is decreased by 



* The fact that we have two read statements in Pi shows that our design is influenced 
by our target language (pl/i in this case). In pl/i, unlike in Pascal, a read must occur on 
an empty file before an end-of-file is indicated (via the variable eof in our case). 
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one every time the loop is executed. When this function becomes < 0, 
we stop. Such a function is a — i; executing i := i + 1 decreases its 
value by 1. When a — i = 0, we have i = a which is when the guard 
evaluates to false and the loop terminates. 
Continuing the refinements we get 



read a 



do not EOF — > | compute sum = £ / 
i:=0 



sum := {sum -0+1 +2+ ••• +/} 

do /' ^ a -*■ /:=/'+ 1 

sum := sum + /' 
od 

print sum 
read a 



od 

P 4 (in pl/i): 



SUM: PROC OPTIONS(MAIN); 
DCL (A /*NEXT INPUT ELEMENT */ 

,//* LOOP VARIABLE •/ 

,Sl/M/*SUM=0+1+2+...+/ V 

)FIXED DEC, 

EOFBIT(1)INIT('0'e); 
ON ENDFILEEOF='1'fl; 

GET LISTW); 
DO WHILE (~EOF); 
/=0; SUM=0; 
DO WHILE (l~=A); 

l=l+A;SUM=SUM+l; END; 
PUT SKIP LIST (' SUM UPTO", A, ' IS ', SUM); 
GET LIST(yA); 
END; 
END SUM; 

Example 3 

Write a program to determine the maximum element value of an m 
X n array A {m, n > 1). 

P : determine the max element value of A 
Pi: /:=0 {last row examined} 

initialize max {max is the maximum element 

of rows 1 • • • i — loop invariant /,} 
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do all rows — » /:— /+1 

not examined max: = maximum(row /', max) 

od 
P 2 : • initialize max is refined to 
max := >A[1, 1] 

• all rows not examined 
is refined to 

/f* m 

• max : = maximum (row i, max) 
is refined as 

y = {max = maximum of rows 1 . . . / - 1 and elements 

1 ... y of row i — loop invariant l 2 ) 
do all elements of -* j :=j + 1 

row /' not examined max := MAX(max, A[i, j]) 

od 

I 2 is the loop invariant. As an exercise, the reader should try and show 
that the loops leave I\ and h invariant, i.e., unchanged. 
P 3 : • all elements of row,/ not examined 
is refined as 
J ' ¥> n 
• max := MAX(max, A[i, j]) 
is refined as 

if max > A[i, j] -* skip 

[]max < A[i, j] -* max := A[i, j] 
fi 

where skip denotes the null statement. 

The iterative feature is the most important feature of a programming 
language. 8 The do • • • od construct allows us to express algorithms 
clearly and succinctly. The above example could have been done better 
had the author not used the do • • • od construct to just simulate the 
while statement. Making fuller use of the do ■ • • od construct, we get 
the following program for the above problem: 

P' 2 - t / := o (number of rows examined so far} 

j ; = o {number of elements of row /' + 1 examined so far} 
initialize max {max is the maximum of all the elements in the first 

/ rows and the first) elements of row / + 1 } — / 
do /'< m rows and j < n — » y:=y + 1 

elements of row /' + 1 max := MAX(max, A[i, j]) 

examined 
[]/' < m rows and all -> move to the next row 

elements of row /' + 1 
examined 
od 
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P' 3 : / : =0; y:=0 

max := A[A , 1 ] {max is the maximum of all the 
elements in the first i rows 
and the first j elements of row / + 1 } — / 
do / < m and / < n — * y':=y'+1 

max := MAX(max, A[i, j]) 
[]/ < m and j = n — > /' := i + 1 ; j := 
od 

Gries also shows that the do • • • od construct usually eliminates the 
need for loop exits necessary in programs that use the while state- 
ment. 8 

Example 4 

The Touch-Tone® telephone provides an easy but limited means of 
communicating with a computer (see Fig. 2). The problem is to write 
a program that provides a simple adding machine to the user. 9 For 
example: 



»User 
input: 



• System 
response: 
(audio) 



of/hook 1 # 5*2 # 4*5 # 



onhook 



one 



"six 


"ten 


point 


point 


two" 


seven 



The characters # and * represent + and • , respectively. 
The following modules are available to the programmer: 
• SPEAK (string) — provides an audio response for the number 

represented by the string. 



1 




2 




3 












4 




5 




6 












7 




8 




9 












• 









# 



Fig. 2— The Touch-Tone® telephone's pushbutton dial. 
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rr 



5 I 3 | null 1 



| 8 • 3 null 


+ | 4 | null 


12 • 1 3 null 



ADD(stringl, string2) - stringl := stringl + string2 

string 1 
string 2 

string 1 

• waitsignal( char)— sets char to the next input character when 
available. 

The input/output specifications written more formally are: 

input: offhook fi # f 2 # ••• # h # onhook, 
integer one or more digits 



where f, = 

(is&n) 



real — one or more digits followed by 

— one or more digits followed by * and at 

least one digit 
— one * followed by at least one digit 



output: SPEAK(SUM,), SPEAK(SUM 2 ), • • ■ , SPEAK(SUM„) 
where SUM, = £*-i f kt 1 < i < n, 
and the audio response occurs after the character # is input. 

We assume that the maximum length of numbers input will be k - 
1. To focus on the refinement process, we make the following additional 
assumptions: 

(i) one addition session, 

(ii) no errors of any kind. 
In the second version of the solution we will eliminate these restric- 
tions. 

Refinement P () : Do telephone addition. 

P x : Compute and speak out the running sum of the numbers 

input. 
P,\ plus := '#'; point := '*' 

waitsignal(c) {c contains the next 

input char to be processed; 
offhook is the first one} 
waitsignal(c) {get char after offhook) 
initially SUM is 

do c t^ onhook' — » read number into A 
ADD(SUM,/A) 
SPEAK(SUM) 

waitsignal(c) {+ consumed} 
od 
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The number variables SUM and A are implemented as strings because 
modules SPEAK and ADD expect strings as arguments. 

Each variable is represented by 

(i) variable of type string, 

{ii) an integer variable that denotes the length of the string, 
where type string = array [1 • • • k] of char. 
In addition to SPEAK and ADD we need 

(i) a procedure ZERO to initialize the numbers represented as strings 
toO, 

(ii) a procedure APPEND to help build a number. 

They are defined as 

procedure ZERO(varX: string; /:integer); 

begin /:=1 ; X[/]:=null end 
procedure APPEND(varX: string; /:integer; c:char); 

begin X[/]:=c; /:=/ + 1 ; X[/]:=null end 

The implementation of numbers and their operations in terms of 
strings is an example of data refinement. 
• Read number into A is refined as 

ZERO A 

doc 7^ plus -> if c = point -> APPEND '•' to A 

[] c ^ point -> APPEND c to A 

fi 

waitsignal(c) 
od 

Collecting the refinements together we get 

const point = '*'; plus = '#'; 
type string = array[A • • k] of char; 
var SUM, A: string; 

/SUM, IA: integer; {lengths of SUM, A) 
begin waitsignal (c); waitsignal (c); 
ZERCKSUM, /SUM); 

do c 7^ 'onhook' — > {read number into A) 
ZEROW, I A) 
do c 5^ plus 

if c = point -> APPENDS, M, '•*) 
[] c t^ point -+ APPENDS, IA, c) 
fi 

waitsignal(c) 
od 

ADD(SUM, A); 
SPEAK(SUM); 
waitsignal(c) 

358 THE BELL SYSTEM TECHNICAL JOURNAL, MARCH 1 981 



od 
end 

Instead of including inline the refinement of "read number into A" 
in the final version of the program, it would have been more appropri- 
ate to make the refinement into a procedure READ and to call READ 
from the final version. This is because READ and the operations ADD 
and SPEAK (which appear in the final program) operate on numbers 
thus representing the same level of abstraction. Also, if an instruction 
appears more than once, then it should perhaps become a procedure 
call. The instruction would then be refined only once. 

In the following 'version of the above program we eliminate the 
restrictions of a single session and no errors. The following types of 
errors are considered possible: 



illegal characters, 

n > 2 decimal points per number, 

only a decimal point— no digits, 

+ follows +, offhook, i.e., null number, 

session starts with other than offhook. 



The initial problem formulation Po is 

do true — » Do telephone addition od 

P, : • Do telephone addition is refined as 

Compute and speak out the running sum of the numbers input 

so far. 
This is refined as 
P 2 : waitsignal(c) 

if c ^ 'offhook ' — > error 
[] c = 'offhook' -> skip 
fi 

waitsignal(c) 

check for valid char {digits, plus, point, 'onhook'} 
initially sum is 
do c 5* 'onhook' — » Read number into A 

if c = plus -> ADD(SUM, A) 
SPEAK(SUM) 
waitsignal(c) 
check for valid char 
[] c = 'onhook' — > skip 
fi 
od 
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Using the procedures APPEND and ZERO defined before, we refine 
read number into A as 

ZERO A 

# digits, # pts : = 0; 

do c is a 

digit or a point 

— > if c is a point — > Append ' • ' to A 

if # pts = -» # pts := # pts + 1 
\] # pts 5^ -> error 
fi 
[] c is a digit — > Append c to A 

# digits := # digits + 1 
fi 

waitsignal(c); 

check for valid char 
od 

if # digits = — > error 
[] # digits ¥> -* skip 
fi 

Continuation of this refinement process is similar to the error-free 
version and we omit it. 

Example 5. McDonald's warehouse problem 9 

Given a list of item cards ordered by item number, produce the 
management report shown in Fig. 3. Each invoice has an item number, 
a code D for delivery, and R for received, and the quantity received or 
delivered. 

Po'. Produce management report 

Pi : a. Print heading 

b. Process the item groups 

c. Print number of item groups changed 



D /- 






.. 


• 






MANAGEMENT REPORT 

ITEM NET CHANGE 
P, 25 
P 2 235 

# CHANGED -20 


V pr 


D 400 




/ w~ 


R 


35 




/- l p2 R 


600 




I PI 




25 




P1 R 


50 













Fig. 3 — From item cards to management report. 
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Line b is refined as 

# changed := 
read item 
do there are more 
item groups 

od 



process an item group 

print item and net change 

# changed := # changed + 1 



• there are more item groups 
is refined as 
not EOF 

• process an item group 
is refined as 

netchange := 
itemgroup # := item# 
do item in group and not EOF 
— » if code = R — » netchange : = 

[] code = D — » netchange : = 

fi 

read item 
od 

• item in group 
is refined as 

itemgroup # = item# 

This concludes the example. 



netchange + Qty 
netchange - Qty 



Example 6 

Using insertion sort, sort the array A (size n > 1) in nondecreasing 
order, i.e., A\ < A-> < • • • < A„, and the new values of array A are a 
permutation of its old values. 

P : Sort the array A 
Pictorially we can characterize the input and output specifications of 
the array A as 

(i) initially 



1 



/ 


N 


sorted 


unsorted 


part 


part 
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(ii) finally 

1 n 

sorted/ \unsorted 

part part 

At some intermediate stage of the sorting we will have 

1 i n 



sorted / \ unsorted 

part part 

This picture corresponds to our loop invariant. It is true initially if 
i = 1. At the end of the loop, i — n implies that the whole array is 
sorted. So the purpose of the loop body will be to exchange the values 
of A in such a way that i can be increased until it equals n. P is 
therefore refined as 
P.: 

/ := 1 {/A[1 • ■ /'] sorted} 

do i ' ^ n — > Extend sorted portion to include A[i + 1 ] 
/ := / + 1 

od 

• Extend sorted portion to include A[i + 1] 
is refined as 

a. t:=A[i+ 1] 

b. shift all elements of A\A ■ • • /'] > t 
one place to the right such that 

A[-\ • . . y - 1] < t and A\J + 1 •••/'+ 1] > t 

c A[j] := r 

• Line b of the above refinement is developed as 

/:-/+ 1 {A[j + 1 ... /+ 1]>f} 

do A[j - 1 ] > t -> shift A[j - 1 ] to the right 

y:=y-1 
od 

On loop termination we have A[j + 1 • • i + 1] > t and A[j — 1] < 
t. This, along with the fact that at the start ^4[1 • • • i] was sorted, 
leads us to A[l • • • / — 1] < t. 

As we have not taken proper care of the end condition, the guard in 
the above loop will cause a subscript error wheny = 1. So we modify 
it to 

yV 1 cand/4[y- 1]>f 
362 THE BELL SYSTEM TECHNICAL JOURNAL, MARCH 1 981 



where cand is similar to and but the second operand is evaluated only 
if j ¥^ 1 (C has a similar operator). This allows for a simple high level 
design. 

• shift A[j - 1] to the right is refined as 

A[j] :=A[j- 1] 

Collecting all the refinements we get 

/:= 1 

do /V n -> t := A[i + 1 ]; j := /' + 1 

do y V 1 cand /\[y - 1 ] > f -> A[j] := >A[y - 1 ] 

y:=y-i 

od 

AM := t 
i := / + 1 
od 

We conclude this section with some comments on program mainte- 
nance and efficiency. Program maintenance, i.e., program modification 
that is due to changing specifications or in response to design errors, 
should be carried out by making changes in the refinements and not 
just the final program. Making changes in only the final program 
renders the design (i.e., refinements) obsolete; consequently, an up- 
dated version of the design will no longer exist and subsequent program 
maintenance becomes increasingly difficult. 

When program specifications change, start from the initial refine- 
ment and locate the refinement affected. Modify this refinement and 
carry the effects of this change down to the last level of refinement. 

When a design error is detected, locate the most abstract refinement 
in which the design error was first made. Then carry the change caused 
by the removal of the design error down to the final refinement. 

A program that does not have the desired efficiency (i.e., perform- 
ance) characteristics must be redesigned. We locate the most abstract 
refinement R where a design decision was made that resulted in these 
characteristics. A proper design modification from refinement R on- 
wards leads to the desired efficiency characteristics. Predecessors of 
refinement R remain unchanged. 

IV. RECURSION 

Stepwise refinement and recursion blend naturally with each other. 
Many programmers avoid recursion and treat it as a novelty.'" Some 
problems are best expressed recursively, even though languages like 
Fortran and cobol are not recursive, and this inhibits programmers 
from thinking and designing recursively. Also, the examples of recur- 
sion in text books, e.g., factorial, Fibonacci numbers, etc., are not 
convincing about its utility. 
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Efficiency has often been cited as a reason against using recursion. 
In these days of increasing software costs and decreasing hardware 
costs, this reason is not very convincing. It is better to have a recursive 
design that is simpler, easier to understand, and easier to show correct 
than a corresponding nonrecursive version. If efficiency is still a 
criterion, then the recursive design can be systematically transformed 
into a nonrecursive one." The following examples illustrate the devel- 
opment of recursive programs: 

1. Write a procedure to print a binary tree with root R (Fig. 4). 
Each node is of the form 



VALUE 



LEFT RIGHT 



where 

(i) VALUE is the data at the node, 

(ii) LEFT, RIGHT are the pointers to the subtrees, 

(Hi) a NIL pointer value denotes the absence of a subtree. 

Initial refinement Po: Print binary tree with root R 



P.: 



if R ¥= NIL -» Print binary tree with root LEFT(fl) 

{left subtree} 
Print VALUE(fl) 

Print binary tree with root RIGHT(fl) 
{right subtree} 
[]R = NIL -> skip 

fl 




Fig. 4— A binary tree with root R. 
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The notation p(x) denotes the component p of the node pointed to by 
jc. Writing the above in Pascal we get: 
procedure print (R: ] node); 
begin 
if R * nil 
then begin print(fl \. LEFT); 

writeln(fl }. VALUE); 
print(R |. RIGHT) 



end 



end 



2. This example illustrates a fast sorting technique called quicksort 
(Hoare 12 ). Array A, with bounds L and U (L < U), is to be sorted in 
nondecreasing order. 

Initial refinement P : Quicksort^, L, U). 

Pi: 

if one element — > skip 

[ ]two elements — » order them 

[ ]more than two elements — » Partition A such that 

L j i U 



< r r > r 



or L > 



C7 



< r > r 



(at least one element per partition 
in this case) 

where r is an arbitrary value 
Quicksorts, L,j) 
Quicksort^, i, U) 



Py. • one element 
is refined as 
U-L = 

• two elements is refined as U — L = 1 

• order them 
is refined as 

if A[U]<A[L] 

[]A[U]>A[L] 

fi 

• more than two elements 
is refined as 
U-L> 1 



swap(/\[L], A[U]) 
skip 
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• Partition A such that ■ • • 
is refined as 

r:=A[(U + L) + 2] 

i-Lj- (j (A[L .. i- 1]<rand/\[y'+ 1 .. U]>r- Invariant/} 

do i < j — > Extend left partition by increasing / 
Extend right partition by decreasing j 
Rearrange elements so that invariant / is 
restored 

od 

Ps\ • Extend left partition • • • 

do /*[/] <r -+ /:=/+ 1 od {/*[/"] >r} 

• Extend right partition • • • 
6oA[j]>r -> /':=/- 1 od {A[j]<r) 

• Rearrange ■ ■ • 

if/<7 — » swap (A[i], A[j]) 
/:=/+ i;j -=j- 1 

[]/>/ -+ skip 
fi 

V. MULTIVERSION PROGRAMS 

A set of programs is said to constitute a program family if it is worth 
while to study programs from the set by first studying the common 
properties of the set and then determining the special properties of the 
individual family members. A typical family is the set of versions of an 
operating system distributed by a manufacturer." Such a family is also 
called a set of multiversion programs. Stepwise refinement enables 
multiversion programs to be developed conveniently and naturally. 

Multiversion programs may be built for the following reasons: u,u 

(i) Economics. It is cheaper to build one program and then modify 
it to get another version than it is to build the second program from 
scratch. 

(ii) Experimentation. Experimental prototypes may be built to study 
the feasibility of building a particular system. The experimental ver- 
sions along with the final program constitute the multiversions. 

(Hi) Faulty program design. Another version of the program is built 
to correct the design faults of a prior version. 

Classically, multiversion programs have been built by first building 
one working version of a program. Another version is built by modify- 
ing this program and so on, as shown in Fig. 5. A set of multiversion 
programs produced as in Fig. 5 has one common ancestor. According 
to Parnas," it is common for the descendants of one program to share 
some of their ancestors' characteristics which are not appropriate to 
the descendants. In building the earlier version, some decisions were 
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o 



INCOMPLETE 
PROGRAM 

FINAL PROGRAM 




X X »-^J »-X 

Fig. 5— Traditional way of building multiversion programs. 

made which would not have been made in the descendant programs 
had they been built independently. Removal of these decisions entails 
a lot of reprogramming. Consequently, programs have performance 
deficiencies because they contain decisions not really suitable for them. 
To build another program version, the program must first be complete 
and working. Relevant changes in an ancestor program that are not 
reflected in the descendant program cause maintenance problems. 

Stepwise refinement allows us to develop multiversion programs 
without the above problems. Never modify a complete program; always 
begin from one of the intermediate refinements which does not contain 
any design decisions unsuitable for the new version. This process is 
illustrated in Fig. 6. 

INITIAL REFINEMENT 



REFINEMENTS 
X FINAL PROGRAM 




Fig. (j — Multiversion program development by stepwise refinement. 
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All decisions made above a branch point are shared by the descen- 
dants. Refinements are developed so that common decisions of multi- 
version programs are above the branch point. A branch point results 
when two or more versions require different strategies (e.g., storage 
management techniques). 

Also refinements below a branch point may be carried out in 
parallel — we do not have to wait until a working program is available. 

VI. SUGGESTIONS FOR REFINEMENT 

1. Develop the program in a gradual sequence of steps. 

2. In each step, refine one or more instructions of the given refine- 
ment. 

3. Terminate the refinement process when the instructions have 
been expressed in the desired programming language or when they can 
be mechanically translated to the programming language. 

4. Use information about the problem and its domain in the for- 
mulation of abstract instructions. 

5. Use notation natural to the problem domain. 

6. Make up abstract instructions as desired. However, they must 
eventually be translatable to an executable form. 

7. Make refinements reflect the instructions they represent in de- 
tailed form. 

8. Be aware that every refinement represents some implicit design 
decision and consider alternate solutions. Keep a written record of the 
major decisions made along with the refinements. 

9. Use recursion when appropriate. Even if the language does not 
support recursion, recursive solutions should still be considered. If 
recursive solutions are selected, they can be systematically converted 
to nonrecursive solutions. 

10. Use data refinement along with instruction refinement. 

11. Postpone representation of data as long as possible. This mini- 
mizes modifications to the design when an alternate representation is 
to be used. 

12. If an instruction appears more than once, use a procedure call; 
refine the instruction only once. Use procedure calls when they clarify 
program structure. 

13. Recognize abstract data types and separate their refinements 
from the rest of the program, i.e., do not refine the data type operations 
in line — use procedure calls. 

14. Try to use loop invariants to develop loops; they give a better 
idea of the instructions in the loop body and the guards. 

15. If a refinement solution does not turn out to be appropriate, 
repeat the refinement process using the additional knowledge derived 
from the previous attempt; stepwise refinement is an iterative process. 
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VII. TOPICS RELATED TO STEPWISE REFINEMENT 

In this section, the idea of abstract data types is explained along 
with the concept of data refinement. This is followed by a discussion 
of the formal specifications of abstract data types. We then show how 
stepwise refinement may help simplify program correctness proofs. 
Finally, we briefly argue that stepwise refinement can be used in 
developing parallel programs. 

7. 1 Abstract data types 

A data type is not only a set of values but also the operations that 
can be performed on them. 15 A primitive data type is a data type that 
is available in the programming language. An abstract data type is a 
data type not available in the programming language and is imple- 
mented in terms of other abstract and primitive data types. 

The implementation of a data type consists of three parts — storage 
allocation, initialization, and the definition of operations. Consider the 
following implementation of the data type integer stack of size 100 in 
pl/i: 

(i) storage allocation 
DCL (S(100) 

,NS /* NUMBER OF ELEMENTS IN S* / 
)FIXED BIN; 
(ii) initialization 

NS m 0; 
(Hi) operations 

PUSH:PROCEDURE(A, NA, X); 

DCL (A(100), NA, X) FIXED BIN; 
IF NA - 100 

THEN PUT SKIP LIST (OVERFLOW ERROR); 

ELSE DO; NA = NA + 1 ; A(NA) = X; END; 
END PUSH; 

POP:PROCEDURE(/\, NA); 

DCL (4(100), M4)FIXED BIN; 
IF NA = 

THEN PUT SKIP LIST (UNDERFLOW ERROR); 
ELSE NA = NA - 1 ; 
END POP; 

TOP:PROCEDURE(/\, NA) RETURNS (FIXED BIN); 
DCL(/\(100). AFFIXED BIN; 
IF NA = 

THEN PUT SKIP LIST( ERROR-STACK EMPTY); 
ELSE RETURN(/\(/v7\)); 
END TOP; 
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EMPTY: PROCEDURES, /V/\)RETURNS(BIT(1»; 
DCL (/\(100), AM)FIXED BIN; 
RETURN(/V/4 = 0); 
END EMPTY; 

Such implementations of abstract data types suffer from many 
disadvantages. Representation details are not hidden from the pro- 
grammer. This leads to the following: 

(i) Representation dependent programming, perhaps for "effi- 
ciency" reasons. For example, the programmer may directly inspect 
the top of the stack instead of using the procedure TOP; a change in 
the representation will then require changes in the program. 

(ii) Violation of the specifications of the abstract data type. For 
example, in case of the stack the programmer may delete an element 
in the middle of the stack. If such an ability is desired, then the 
specifications should be changed. 

(Hi) Inadvertent or malicious violation of the integrity of the ab- 
stract data type. For example, NS could be set to even if the stack is 
not empty. 

In addition, the programmer has to be concerned about which 
components of the representation have to be passed as arguments to 
the procedures associated wth the abstract data type. To be uniform, 
we have passed all the components of the stack representation for 
every operation. 

Modern programming languages such as clu" 1 " 18 and Alphard 1 pro- 
vide data abstraction features, called clusters and forms, respectively, 
that remove the above problems. In addition, they support data 
refinement. We use clu's clusters to illustrate data refinement and 
give an example of programming with abstract data types. The nota- 
tion used is similar to that of clu. 

stack = cluster is push, pop, top, empty; 
rep = record [ns: integer; 

s: array[ 1 ■• 1 00] of integer] 
create = oper( ) returns cvt; 
s.rep 
s.ns:=0 
return s 
end 
push = oper(a:cvt, x:integer) 
if a.ns = 100 
then overflow error 
else begin a.ns := a.ns + 1 
a.s[a./?s] := x 
end 
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end 
pop = oper(axvt) 
if a.ns = 

then underflow error 
else a.ns := a.ns - 1 
end 
top = oper(axvt) returns integer 
if a.ns = 

then stack empty error 
else return a. s. [a.ns] 
end 
empty = oper(a:cvt) returns boolean 
return a.ns = 
end 
end stack 
Having defined the stack cluster, the programmer can declare vari- 
ables of type stack, e.g., b:stack. 

The first line of the stack definition states that the operations 
available to stack users are push, pop, top, and empty. The operation 
must be prefixed by the type name, e.g., the special operation create 
is automatically executed when a variable of type stack is declared. 

The line beginning "rep = " specifies that a stack is represented by 
an integer array and an integer. This information cannot be used 
outside the cluster, thus making the rest of the program representation 
independent. 

The special symbol cvt (convert) means that the variable is of the 
abstract type outside the operation and of the representing type inside 
the operation. 

An operating system example 

Suppose we are writing an operating system. Jobs are to be sched- 
uled according to their priority (10 being the highest and 1 the lowest). 
The next job to be executed is the one with the highest priority. If 
there is more than one job with the highest priority, then the one 
selected for execution is the one that waited the most (FIFO): 
begin (operating system} 

Add job j with priority p to the list of 
jobs waiting for execution 

Wait until there is a job to execute 
let j be the next job to be executed 

end (operating system} 
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To implement the job scheduling we define a cluster called spq (system 
of priority queues), with operations add, empty , and next job. 

spq = cluster is add, empty, nextjob 
rep = array[1 • • 1 0] of queue 
create = oper( ) returns cvt 
s:rep 
return s 
end 
add = oper(s:cvt, job:integer, prty:1 •• 10) 
queue$add(s[prty], job#) 
end 
empty = oper(sxvt) returns boolean 
/: integer := 
while I 3* 1 do 

begin /':=/+ 1 

if queue$empty(s[/']) then return false 
end 
return true 
end 

nextjob = oper(sxvt) returns integer 
/integer := 11 
y: integer 
while / *M do 
begin /:=/'- 1 

if ~ queue$empty(s[/']) 
then begin y := queue$front(s[/]) 
queue$delete(s[/]) 
return j 
end 
end 
end 
end spq 

The cluster spq is implemented in terms of the abstract data type 
queue. For example, cluster spq's operation add uses cluster queue's 
operation add, i.e., queue$add. We refine instructions of the abstract 
data type queue by implementing a queue cluster. For this example, 
we assume that no more than 50 jobs of the same priority will be 
waiting at the same time. We shall use a wrap-around array represen- 
tation for the queue in which 

(i) an array of size 51 is used; only 50 elements can be stored in the 
queue, 

(ii) F= L means that the queue is empty, 
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{Hi) mod(F, 51) + L points to the next element in the queue, 
(iv) mod(L, 51) points to the last element in the queue, 
(v) mod(L, 51) + 1 = F means that the queue is filled. 

queue = cluster is delete, add, front, empty; 

rep = record[a:array[1 • • 51] of integer; F, L:integer] 
create = oper( )returns cvt 

q:rep 

q.F:=0 

q.L := 

end 

delete = oper(qrcvt); 
if q.F = q.L 

then error-empty queue 
else q.F := mod(q.F, 51 ) + L 
end 
add = oper(q:cvt, j:integer) 

if mod(q.L, 51)4-1 = q.F 
then error-queue full 
else begin q.L = mod(q.L, 51) + 1 
q.a[q.L] := j 
end 
end 

front = oper(q:cvt) returns integer 

if q.F = q.L 

then error-empty queue 

else return q-a[mod(F, 51) + 1] 
end 

empty = oper(qxvt) returns boolean 

return q.F = q.L 

end 
end queue 

7.2 Formal specifications of abstract data types 

In this section, we consider the formal specifications of abstract data 
types. In particular, we take a brief look at the algebraic specification 
technique proposed by Guttag.' 9 - Abstract data types are imple- 
mented in terms of other data types by the refinement or decomposi- 
tion of specifications. 

The algebraic specifications consists of two parts: 

(i) the syntax— here the operations of the data type are listed 
indicating the number of arguments, the argument types, and the 
result type. 
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(ii) the semantics — here axioms are given that relate the values 
created by the operations. 

In the basic notation which we will use, the operations are functions 
without side effects; none of the arguments are changed. Guttag 21 has 
extended the notation to allow for changes in arguments, i.e., to allow 
procedures. 

We shall present algebraic specifications for the abstract data type 
stack considered earlier. We shall then give specifications for an array. 
Finally we shall refine the stack operations in terms of array operations. 
To keep the specifications as simple as possible, we shall consider 
unbounded (i.e., infinite size) stacks and arrays. 
Stack specifications: 



1. 


type stack 


2. 


syntax 


3. 


create( ) — > stack 


4. 


push(stack, integer) — > stack 


5. 


pop(stack) — > stack 


6. 


top(stack) — * integer 


7. 


empty(stack) — > boolean 


8. 


semantics 


9. 


declare s:stack; x:integer 


10. 


pop(create( )) = underflow error 


11. 


pop(push(s, x)) = s 


12. 


top(create( )) = empty stack error 


13. 


top(push(s, x)) = x 


14. 


empty(create( )) = true 


15. 


empty(push(s, x)) = false 



Line 3: specifies the syntax of the create operation. The result of 

calling create, which has no parameters, is an object of type 

stack. 
Line 4: operation push takes as input a parameter of type stack and 

a parameter of type integer. It returns a value of type stack. 
Line 10: The result of applying the pop operation on a stack that has 

just been created is an underflow error. "=" is the equality 

operator (not assignment). 
Line 11: The result of popping a stack s on which the last operation 

was to push a value x is the initial stack s. 
These specifications specify the abstract data type completely. For 
details on how to construct the specifications, see Ref. 20. We now 
give the specification for the type array which will be used to imple- 
ment the type stack. 

1 . type array 

2. syntax 
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3. createarray( ) -> array 

4. assign(array, integer, integer) — » array 

5. access(array, integer) -* integer 

6. semantics 

7. declare a:array; /', y, x:integer 

8. access(createarray( ), /) = undefined error 

9. access(assign(a, /", x), /) 

= if / = y 
then x 
else access(a, j) 

Operation assign(a, i, x) stands for an array whose ith element has 
been assigned the value x. Operation access(a, i) stands for the ith 
element of a. 

We now implement the abstract data type stack by decomposing 
stack operations in terms of array operations. We give axioms called 
programs that give the effect of stack operations in terms of array 
operations. 

1 . stack implementation 

2. syntax 

3. STK(array, integer) -» stack 

4. programs 

5. declare a:array, f, x:integer 

6. create( ) = STK(createarray( ), 0) 



7. push(STK(a, t), x) = STK(assign(a, f + 1 , x), 

f+1) 

8. pop(STK(a, 0) = if f = 

then underflow error 
else STK(a, t - 1 ) 

9. top(STK(a, f)) = if t = 

then empty stack error 
else access(a, t) 

10. empty(STK(a, 0) = (r = 0) 

Given the formal specifications for an abstract data type, an initial 
inefficient implementation, called the direct implementation, can be 
automatically generated. 19 Thus one can test some facets of a high- 
level data type before fixing upon a particular implementation. Thus 
a true top-down implementation methodology can be achieved. 

7.3 Program correctness 

Stepwise refinement provides a natural environment for reducing 
the problem of showing the correctness of a large program into showing 
the correctness of several smaller programs. 

A program is said to be correct if it meets its input and output 
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specifications (which may include performance criteria). Alternately, 
a correct program is one that transforms a state (i.e., data values) 
representing the input specifications into one representing the output 
specifications. A program is thus viewed as a specification transformer 
(Dijkstra 1 ' calls it a predicate transformer). Let 

(i) I and O be the input and output specifications for the problem 
being solved. 

(ii) P be the initial problem formulation and P* the corresponding 
final program. 

Then we say that P<i has been solved correctly if P* is correct with 
respect to / and O. If P<> is a nontrivial problem, then proving the 
correctness of Po will be correspondingly nontrivial. 

Stepwise refinement allows the correctness proof of a program to be 
reduced to the correctness proofs of smaller programs. Suppose P is 
refined or decomposed into the subproblems Pio, Pu, • • •, P\„, with 
each Pu having specifications S, and S,-+i (So = I and S„ +] = 0). The 
problem of proving P* correct is now reduced to proving P*, (0 < i < 
n) correct, where P*> is the program corresponding to P )y . Owicki 22 
provides an example of such a correctness proof. 

In summary, stepwise refinement provides a natural medium for a 
difficult proof to be decomposed into several smaller proofs. A proof is 
any convincing demonstration of a program's correctness. However, 
the conventional approach to understanding programs in terms of how 
computers execute them is inadequate. A more mathematical approach 
is needed even if it is used informally. 2 '' Alagic 24 contains many exam- 
ples of programs designed with correctness proofs in mind. 

7.4 Parallel programs 

The development of parallel programs is no different than the 
development of sequential programs as far as stepwise refinement is 
concerned. Instead of using only sequential constructs, like begin Si , 
S? ; • • • ; s„ end in Pascal, we now use constructs for parallel program- 
ming, 2 '' m as shown below: 

(i) cobegin S, , S 2 S„ coend 

The statements S if S>, . . . , S„ are executed in parallel. 
(ii) when b^ — » SL A 
Qb 2 -> SL 2 



[]b n -> SL n 
end 

Wait till one of the guards b, is true and then execute the 
corresponding statement list 
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(Hi) cycle b, -» SL, 
[]b 2 -» SL 2 



end 



Endless repetition of a when statement. 
If several guards are true within a when or a cycle statement, then 
one of the corresponding statement lists is executed nondeterministi- 
cally. 

VIII. CONCLUSIONS 

In this tutorial, we have tried to illustrate the stepwise refinement 
technique, its advantages, and related topics. Stepwise refinement can 
be learned easily with some practice. It blends in naturally with the 
newer concepts in programming languages and methodology (e.g., 
abstract data types, parallel programming, etc.). 

Stepwise refinement does not provide a solution to the problem. No 
methodology, old or new, is going to discover algorithms (i.e., problem 
solutions) for the programmer. The algorithms must come from the 
programmer's education, experience, and ingenuity. 

Stepwise refinement encourages the development of a problem 
solution in a systematic fashion that is easy to understand, modify, 
and improve upon. The various refinements should not be discarded 
once the final program version is arrived at. They are part of the 
program documentation. Understanding the final program without 
them is hard even if the program is small (e.g., the eight-line final 
program version of insertion sort in Section III). 

The reader is urged to try stepwise refinement on some problems, 
especially large ones. 
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